packages/components/src/ui/calendar.tsx (1)

45-47: Consider type-safe props spreading for icon components

While the changes improve type safety with Partial<CustomComponents>, the current props spreading could be more specific.

Consider explicitly typing and spreading only the necessary props:

- IconLeft: ({ ...props }) => <ChevronLeft className="h-4 w-4" {...props} />,
- IconRight: ({ ...props }) => <ChevronRight className="h-4 w-4" {...props} />,
+ IconLeft: ({ className, ...props }: React.ComponentProps<'svg'>) => (
+   <ChevronLeft className={cn("h-4 w-4", className)} {...props} />
+ ),
+ IconRight: ({ className, ...props }: React.ComponentProps<'svg'>) => (
+   <ChevronRight className={cn("h-4 w-4", className)} {...props} />
+ ),

This approach:

1. Explicitly types the props as SVG element props
2. Properly handles className merging
3. Makes it clear what props are expected

packages/components/src/ui/radio-group.tsx (1)

70-70: Consider adding null-safe error message access.

To improve type safety, consider using optional chaining for error message access:

-{fieldState.error && <FormMessage Component={components?.FormMessage}>{fieldState.error.message}</FormMessage>}
+{fieldState.error?.message && (
+  <FormMessage Component={components?.FormMessage}>{fieldState.error.message}</FormMessage>
+)}

apps/docs/src/remix/remix-textarea.stories.tsx (5)

12-16: Consider adding a maximum length constraint

While the minimum length validation is good, consider adding a maximum length constraint to prevent potential abuse and ensure reasonable input sizes.

 const formSchema = z.object({
-  description: z.string().min(10, 'Description must be at least 10 characters'),
+  description: z.string()
+    .min(10, 'Description must be at least 10 characters')
+    .max(1000, 'Description must not exceed 1000 characters'),
 });

---

22-50: Consider showing loading state during form submission

The component handles form state well, but could benefit from showing a loading indicator during submission.

       <fetcher.Form onSubmit={methods.handleSubmit} method="post" action="/">
         <div className="space-y-4 w-[400px]">
           <RemixTextarea
             name="description"
             label="Description"
             description="Enter a description (minimum 10 characters)"
             placeholder="Type your description here..."
           />
-          <Button type="submit" className="w-full">Submit</Button>
+          <Button 
+            type="submit" 
+            className="w-full"
+            disabled={fetcher.state === 'submitting'}
+          >
+            {fetcher.state === 'submitting' ? 'Submitting...' : 'Submit'}
+          </Button>
           {fetcher.data?.message && (
             <p className="text-green-600 text-sm">{fetcher.data.message}</p>
           )}

---

52-76: Enhance type safety for error responses

Consider defining explicit types for error responses to improve maintainability and type safety.

+type ValidationError = {
+  errors: {
+    description?: {
+      type: string;
+      message: string;
+    };
+  };
+  defaultValues: FormData;
+};
+
+type SuccessResponse = {
+  message: string;
+};
+
-async function handleFormSubmission(request: Request) {
+async function handleFormSubmission(request: Request): Promise<ValidationError | SuccessResponse> {

---

78-102: Consider enhancing Storybook documentation

The metadata could be improved with additional documentation parameters.

   parameters: {
     layout: 'centered',
     docs: {
       description: {
-        component: 'A textarea component that integrates with Remix Form and provides validation feedback.',
+        component: `
+          A textarea component that integrates with Remix Form and provides validation feedback.
+          
+          ## Features
+          - Integrates with Remix Form
+          - Zod validation
+          - Error handling
+          - Success feedback
+          
+          ## Usage
+          \`\`\`tsx
+          <RemixTextarea
+            name="description"
+            label="Description"
+            description="Helper text"
+          />
+          \`\`\`
+        `,
       },
     },
   },

---

104-135: Enhance test coverage with additional assertions

While the test scenarios are comprehensive, consider adding more assertions for better coverage.

     // Test validation error
     await userEvent.clear(textarea as HTMLTextAreaElement);
     await userEvent.type(textarea as HTMLTextAreaElement, 'short');
+    expect(textarea).toHaveValue('short');
     await userEvent.click(canvasElement.querySelector('button[type="submit"]') as HTMLButtonElement);
     expect(canvasElement.querySelector('.form-message')).toHaveTextContent(
       'Description must be at least 10 characters'
     );
+    expect(canvasElement.querySelector('button[type="submit"]')).not.toBeDisabled();

     // Test server error
     await userEvent.clear(textarea as HTMLTextAreaElement);
     await userEvent.type(textarea as HTMLTextAreaElement, INVALID_CONTENT);
+    expect(textarea).toHaveValue(INVALID_CONTENT);
     await userEvent.click(canvasElement.querySelector('button[type="submit"]') as HTMLButtonElement);
     expect(canvasElement.querySelector('.form-message')).toHaveTextContent(CONTENT_ERROR);

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Search for Calendar component usage to verify compatibility
rg -t tsx -t jsx "Calendar" --glob '!{*.test.*,*.spec.*}' -A 2 -B 2

#!/bin/bash
# Search for Calendar component usage with ripgrep, without file type filtering
rg "Calendar" --glob '!{*.test.*,*.spec.*}' -A 2 -B 2

# Also check for any potential imports of the Calendar component
rg "import.*Calendar" --glob '!{*.test.*,*.spec.*}'

#!/bin/bash
# Description: Check for consistent form field implementation patterns across components

# Check for similar form field components and their error handling
ast-grep --pattern 'render={({ field, fieldState }) => {
  $$$
  {fieldState.error$$$}
  $$$
}}'

# Check for FormMessage usage patterns
rg -A 2 "FormMessage.*Component={components\?.FormMessage}" 

#!/bin/bash
# Let's try a different approach to verify form field patterns

# Check for form field components with error handling
rg -U "render=\{\(\{.*fieldState.*\}\).*=>" --type ts

# Check FormMessage usage with proper escaping
rg "FormMessage.*Component=" --type ts

# Look for other form field components for comparison
ast-grep --pattern 'const $_ = forwardRef<$_, $_Props>(($_, ref) => {
  $$$
  return (
    <Controller
      $$$
    />
  )
})'

packages/components/src/remix/remix-textarea.tsx (1)

8-21: Consider adding JSDoc documentation

The component would benefit from JSDoc documentation explaining its purpose, usage, and integration with Remix forms. This would help developers understand how to properly use this wrapper component.

Add documentation like this:

+/**
+ * A Remix-compatible textarea component that integrates with remix-hook-form.
+ * Provides form validation and error handling through the Remix form context.
+ *
+ * @example
+ * ```tsx
+ * <RemixTextarea name="description" placeholder="Enter description..." />
+ * ```
+ */
 export function RemixTextarea(props: RemixTextareaProps) {

packages/components/src/remix/remix-switch.tsx (2)

15-23: Consider if memoization is necessary here

The memoization of the components object might be unnecessary in this case because:

1. The object is static and simple
2. React's reconciliation is already efficient with simple object literals
3. The memoization itself has a small performance cost

Consider one of these alternatives:

- const components = useMemo(
-   () => ({
-     FormDescription: RemixFormDescription,
-     FormControl: RemixFormControl,
-     FormLabel: RemixFormLabel,
-     FormMessage: RemixFormMessage,
-   }),
-   []
- );

+ // Option 1: Define it outside the component since it's static
+ const switchComponents = {
+   FormDescription: RemixFormDescription,
+   FormControl: RemixFormControl,
+   FormLabel: RemixFormLabel,
+   FormMessage: RemixFormMessage,
+ };

+ // Option 2: Define it directly in the component if you prefer keeping it scoped
+ const components = {
+   FormDescription: RemixFormDescription,
+   FormControl: RemixFormControl,
+   FormLabel: RemixFormLabel,
+   FormMessage: RemixFormMessage,
+ };

---

1-1: Consider organizing imports

The imports mix React core, third-party libraries, and local imports.

Consider organizing imports into groups:

- import { useMemo, type ComponentPropsWithoutRef } from 'react';
- import { useRemixFormContext } from 'remix-hook-form'
- import { Switch } from '../ui/switch'
- import { RemixFormControl, RemixFormDescription, RemixFormLabel, RemixFormMessage } from './remix-form';

+ // React core
+ import { type ComponentPropsWithoutRef } from 'react';
+ 
+ // Third-party libraries
+ import { useRemixFormContext } from 'remix-hook-form'
+ 
+ // Local imports
+ import { Switch } from '../ui/switch'
+ import { 
+   RemixFormControl,
+   RemixFormDescription,
+   RemixFormLabel,
+   RemixFormMessage
+ } from './remix-form';

packages/components/src/ui/textarea.tsx (1)

6-15: Add JSDoc documentation for the TextareaProps interface

The generic type parameters and props would benefit from documentation to improve developer experience.

Consider adding documentation like this:

+/**
+ * Props for the Textarea component
+ * @template TFieldValues - The type of the form values
+ * @template TName - The type of the field name
+ */
export interface TextareaProps<
  TFieldValues extends FieldValues = FieldValues,
  TName extends FieldPath<TFieldValues> = FieldPath<TFieldValues>
> extends Omit<TextareaHTMLAttributes<HTMLTextAreaElement>, 'name'> {
+  /** The form control from react-hook-form */
  control?: Control<TFieldValues>;
+  /** The name of the field */
  name: TName;
+  /** Optional label text */
  label?: string;
+  /** Optional description text */
  description?: string;
+  /** Optional custom components for form elements */
  components?: Partial<FieldComponents>;
}

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Check for similar useMemo patterns in other Remix form components
# Expected: Find similar patterns to confirm consistency

rg -A 5 "useMemo.*FormControl.*FormLabel.*FormDescription.*FormMessage" packages/components/src/remix/

#!/bin/bash
# Let's search for individual useMemo patterns in Remix components
# to get a better understanding of the memoization patterns

# Search for useMemo in remix components
rg "useMemo\(" packages/components/src/remix/ -B 1 -A 3

# Also search for component definitions to understand the context
ast-grep --pattern 'const $_ = useMemo(() => ({
  $$$
}), $_)'

#!/bin/bash
# Search for RemixTextarea usage patterns
echo "Searching for RemixTextarea usage patterns..."
rg -A 3 "<RemixTextarea"

# Check if there are any direct Textarea usages that should be using RemixTextarea instead
echo "Checking for potential missed Remix integration opportunities..."
rg -A 3 "<Textarea" | grep -v "RemixTextarea"

#!/bin/bash
# Search for similar component customization patterns in form components
echo "Searching for FormLabel component customization..."
rg "FormLabel Component={components\?.FormLabel}" --type tsx

echo "Searching for FormControl component customization..."
rg "FormControl Component={components\?.FormControl}" --type tsx

echo "Searching for FormDescription component customization..."
rg "FormDescription Component={components\?.FormDescription}" --type tsx

echo "Searching for FormMessage component customization..."
rg "FormMessage Component={components\?.FormMessage}" --type tsx

#!/bin/bash
# Search for similar component customization patterns in form components with escaped special characters
echo "Searching for FormLabel component customization..."
rg "FormLabel Component=\{components\?\." --type tsx

echo "Searching for FormControl component customization..."
rg "FormControl Component=\{components\?\." --type tsx

echo "Searching for FormDescription component customization..."
rg "FormDescription Component=\{components\?\." --type tsx

echo "Searching for FormMessage component customization..."
rg "FormMessage Component=\{components\?\." --type tsx

#!/bin/bash
# Search for similar component customization patterns in form components
echo "Searching for FormLabel component customization..."
rg "FormLabel Component=\{components\?\." 

echo "Searching for FormControl component customization..."
rg "FormControl Component=\{components\?\."

echo "Searching for FormDescription component customization..."
rg "FormDescription Component=\{components\?\."

echo "Searching for FormMessage component customization..."
rg "FormMessage Component=\{components\?\."

# Also search for files that might contain form components
echo -e "\nSearching for form-related files..."
fd -e tsx -e ts "form" -t f

packages/components/src/ui/text-field.tsx (1)

25-46: Well-structured component implementation

The component demonstrates good architectural practices:

• Proper integration with react-hook-form
• Flexible component composition through the components prop
• Comprehensive error handling with fieldState
• Type-safe implementation with generics

Consider adding unit tests to verify the behavior with both controlled and uncontrolled usage patterns.

packages/components/src/ui/textarea.tsx (2)

6-15: Consider adding JSDoc documentation

The interface is well-typed and provides excellent type safety for form integration. Consider adding JSDoc documentation to explain the generic parameters and props for better developer experience.

Example documentation:

/**
 * Props for the Textarea component.
 * @template TFieldValues - The type of the form values
 * @template TName - The type of the field name
 */
export interface TextareaProps<
  TFieldValues extends FieldValues = FieldValues,
  TName extends FieldPath<TFieldValues> = FieldPath<TFieldValues>
> {
  /** The form control from react-hook-form */
  control?: Control<TFieldValues>;
  /** The name of the field in the form */
  name: TName;
  /** Optional label text */
  label?: string;
  /** Optional description text */
  description?: string;
  /** Optional component overrides */
  components?: Partial<FieldComponents>;
}

---

32-34: Consider props spreading order

The current order of spreading props might allow overriding of important field properties. Consider reversing the order to ensure field properties take precedence.

-{...field}
-{...props}
-ref={field.ref}
+{...props}
+{...field}
+ref={useMergeRefs([ref, field.ref])}

packages/components/src/ui/switch.tsx (1)

26-26: Review ref handling changes

The ref handling has been restructured:

1. The main ref is now attached to the FormItem wrapper
2. The Switch primitive now uses field.ref from react-hook-form

This change improves form integration but introduces a potential gotcha:

• The ref now points to the wrapper div instead of the switch input
• This might affect accessibility tools or custom logic expecting the ref to point to the input element

Consider documenting this behavior change in the component's documentation or adding a second ref prop specifically for the switch input if needed.

Also applies to: 33-33

packages/components/src/ui/date-picker.tsx (2)

40-40: Consider ref handling implications

Moving the ref to FormItem wraps the entire form control group, which is good for form layouts but might affect direct DOM manipulation needs. Ensure this aligns with your use cases.

Consider documenting this ref behavior in component documentation to help consumers understand what element they're referencing.

---

Line range hint 50-57: Improved form integration with field.ref

The Button now correctly uses field.ref from react-hook-form, which is the recommended approach for form library integration. This ensures proper form state management and validation handling.

Consider adding aria-invalid and aria-describedby attributes for better accessibility:

 <Button
   ref={field.ref}
   variant="outline"
+  aria-invalid={!!fieldState.error}
+  aria-describedby={fieldState.error ? `${name}-error` : undefined}
   className={cn(
     'w-[280px] justify-start text-left font-normal',
     !field.value && 'text-muted-foreground',
     buttonClassName,
   )}
 >

packages/components/src/remix/remix-form.tsx (2)

43-57: Consider enhancing error message handling

The implementation looks good with proper ref forwarding and accessibility attributes. However, consider adding error message logging or telemetry for better debugging in production.

 export const RemixFormControl = forwardRef<HTMLDivElement, ComponentPropsWithoutRef<typeof FormControl>>(
   (props, ref) => {
     const { error, formItemId, formDescriptionId, formMessageId } = useRemixFormField();
+    // Consider adding error logging/telemetry here
+    if (error) {
+      console.error('Form control error:', { fieldId: formItemId, error });
+    }
     return (
       <FormControl
         ref={ref}

---

68-73: Enhance error handling and accessibility

While the implementation is good, consider these improvements:

1. Add null checks for error message
2. Include aria-invalid attribute for better accessibility

 export const RemixFormMessage = forwardRef<HTMLParagraphElement, ComponentPropsWithoutRef<typeof FormMessage>>(
   (props, ref) => {
     const { error, formMessageId } = useRemixFormField();
-    return <FormMessage ref={ref} formMessageId={formMessageId} error={error?.message} {...props} />;
+    const errorMessage = error?.message ?? null;
+    return (
+      <FormMessage
+        ref={ref}
+        formMessageId={formMessageId}
+        error={errorMessage}
+        aria-invalid={!!errorMessage}
+        {...props}
+      />
+    );
   },
 );

packages/components/src/ui/checkbox.tsx (1)

35-38: LGTM: Improved form integration

The ref handling changes correctly integrate with react-hook-form by:

1. Using field.ref for form state management
2. Forwarding the outer ref to FormItem for layout/accessibility

Consider adding a comment explaining this ref handling strategy:

 <FormItem className={cn('flex flex-row items-start space-x-3 space-y-0', className)} ref={ref}>
   <FormControl Component={components?.FormControl}>
     <CheckboxPrimitive.Root
+      // Using field.ref for react-hook-form integration
       ref={field.ref}

packages/components/src/ui/radio-group.tsx (1)

70-70: Consider enhancing error message accessibility

The conditional error message rendering is a good improvement. However, consider adding an aria-live region to ensure screen readers announce when error messages appear.

- {fieldState.error && <FormMessage Component={components?.FormMessage}>{fieldState.error.message}</FormMessage>}
+ {fieldState.error && (
+   <div aria-live="polite">
+     <FormMessage Component={components?.FormMessage}>{fieldState.error.message}</FormMessage>
+   </div>
+ )}

packages/components/src/ui/input-otp.tsx (2)

105-105: Well-structured ref handling for form integration

Good use of field.ref for form control integration while maintaining separation of concerns between form control refs and component container refs. This architecture allows for better form state management through react-hook-form while keeping the component container independently referenceable.

---

Line range hint 114-124: Consider making slot rendering more dynamic

The current implementation handles 8 slots specifically, but could be more flexible by dynamically rendering slots based on maxLength.

Consider refactoring to use Array.from for dynamic slot rendering:

-                <InputOTPGroup>
-                  <InputOTPSlot index={0} />
-                  <InputOTPSlot index={1} />
-                  <InputOTPSlot index={2} />
-                  {isEightSlots && <InputOTPSlot index={3} />}
-                </InputOTPGroup>
-                <InputOTPSeparator />
-                <InputOTPGroup>
-                  <InputOTPSlot index={isEightSlots ? 4 : 3} />
-                  <InputOTPSlot index={isEightSlots ? 5 : 4} />
-                  <InputOTPSlot index={isEightSlots ? 6 : 5} />
-                  {isEightSlots && <InputOTPSlot index={7} />}
-                </InputOTPGroup>
+                {Array.from({ length: Math.ceil(maxLength/4) }).map((_, groupIndex) => (
+                  <>
+                    {groupIndex > 0 && <InputOTPSeparator />}
+                    <InputOTPGroup>
+                      {Array.from({ length: Math.min(4, maxLength - groupIndex * 4) }).map((_, slotIndex) => (
+                        <InputOTPSlot key={groupIndex * 4 + slotIndex} index={groupIndex * 4 + slotIndex} />
+                      ))}
+                    </InputOTPGroup>
+                  </>
+                ))}

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Check for potential formatter conflicts

# Check for Prettier config
echo "Checking for Prettier config files..."
fd -t f "^\.prettier" -t f "prettier\.config\."

# Check for ESLint config
echo "Checking for ESLint config files..."
fd -t f "^\.eslint" -t f "eslint\.config\."

# Check package.json for formatting-related dependencies
echo "Checking package.json for formatter dependencies..."
if [ -f "package.json" ]; then
    jq '.dependencies + .devDependencies | with_entries(select(.key | test("prettier|eslint|biome")))' package.json
fi

#!/bin/bash
# Check for any other formatter or linter configurations
echo "Checking for any config files..."
fd -e json -e js -e cjs -e yaml -e yml | grep -iE '(prettier|eslint|biome|format)'

# Check if there are any other VS Code settings that might conflict
echo "Checking VS Code settings..."
if [ -f ".vscode/settings.json" ]; then
    jq '.[".js"]?, .[".jsx"]?, .[".ts"]?, .[".tsx"]?, .["javascript"]?, .["javascriptreact"]?' .vscode/settings.json
fi

# Check for biome configuration
echo "Checking for Biome config..."
fd "biome.json"

#!/bin/bash
# Search for TextField ref usage in the codebase
rg -A 3 "TextField.*ref" --type tsx --type ts

#!/bin/bash
# Search for TextField ref usage in the codebase with ripgrep
rg -A 3 "TextField.*ref" --type typescript

#!/bin/bash
# Search for TextField component usage with useRef
rg -A 3 "useRef.*TextField" --type typescript

#!/bin/bash
# Find all TypeScript/TSX files that import TextField
rg "import.*TextField.*from.*components" --type typescript

#!/bin/bash
# Find all TypeScript/TSX files in the repository
fd "\.(tsx|ts)$" -x rg -l "TextField"

#!/bin/bash
# Check content of files that use TextField for ref usage
cat "./apps/docs/src/remix/remix-text-field.stories.tsx" "./packages/components/src/remix/remix-text-field.tsx"

#!/bin/bash
# Search for useRef or ref patterns in files containing TextField
rg "useRef|ref=" "./apps/docs/src/remix/remix-text-field.stories.tsx" "./packages/components/src/remix/remix-text-field.tsx"

#!/bin/bash
# Search for TextField usage in the entire codebase with grep
rg -A 5 "<TextField" .

# Also search for any direct ref usage with TextField
rg -A 5 "TextField.*ref|ref.*TextField" .

#!/bin/bash
# Search for Switch component usage with ref
ast-grep --pattern 'const $_ = useRef<$_>();
$$$
<Switch ref={$_} $$$'

# Also search for direct ref assignments
rg -A 2 'ref={.*}.*<Switch'

#!/bin/bash
# Search for Switch component usage with ref, fixing the regex
rg -U '<Switch.*ref=' -A 2

# Search for useRef declarations followed by Switch usage within a reasonable context
rg -U 'useRef.*\n.*(?s:.)*?<Switch' --multiline

# Search for any Switch component usage to understand the context
rg -U '<Switch' -B 2 -A 2

#!/bin/bash
# Search for similar date picker implementations to verify ref handling patterns
ast-grep --pattern 'forwardRef<HTMLDivElement, $props>($$$)' 

#!/bin/bash
# Let's search for the complete DatePicker implementation to understand the ref usage
ast-grep --pattern 'export const DatePicker = forwardRef<$type, $props>($$$)'

# Also search for FormItem usage within DatePicker to understand ref forwarding
rg "FormItem" "packages/components/src/ui/date-picker.tsx" -A 5 -B 5

# Search for Button usage to verify ref handling
rg "Button" "packages/components/src/ui/date-picker.tsx" -A 5 -B 5

#!/bin/bash
# Search for any direct ref usage of this component that might be affected
rg -l "useRef.*<.*Checkbox" 
rg "ref=.*{.*}" --type tsx -A 2 -B 2 | grep -B 2 -A 2 "Checkbox"

#!/bin/bash
# Search for any direct ref usage of this component that might be affected
rg "useRef.*Checkbox"

# Search for ref prop usage with Checkbox component
rg "ref.*=.*" --type tsx -A 2 -B 2 | rg -B 2 -A 2 "<Checkbox"

# Look for Checkbox component usage patterns
rg "<Checkbox" --type tsx -A 2 -B 2

# Check if there are any stories or tests using refs with Checkbox
fd "checkbox" -e stories.tsx -e test.tsx -e spec.tsx --exec rg "useRef|ref=" {}

#!/bin/bash
# Search for any direct ref usage of this component that might be affected
rg "useRef.*Checkbox"

# Search for ref prop usage with Checkbox component
rg -t ts -t tsx "ref.*=.*" -A 2 -B 2 | rg -B 2 -A 2 "<Checkbox"

# Look for Checkbox component usage patterns
rg -t ts -t tsx "<Checkbox" -A 2 -B 2

# Check if there are any stories or tests using refs with Checkbox
fd -e ts -e tsx -g "*checkbox*" | xargs rg "useRef|ref="

#!/bin/bash
# Search for similar form field components to verify ref type consistency
ast-grep --pattern 'export const $FIELD = forwardRef<HTMLDivElement, $Props>'

#!/bin/bash
# Let's try a broader pattern to find form field components using forwardRef
ast-grep --pattern 'export const $_ = forwardRef<$TYPE, $_>('

# Also search for specific form field components
rg -l "FormField|InputField|TextField|SelectField|CheckboxField|RadioField" --type ts

#!/bin/bash
# Let's examine the ref types in these specific form-related components
echo "=== text-field.tsx ==="
cat packages/components/src/ui/text-field.tsx | grep -A 1 "export const.*forwardRef"

echo -e "\n=== form.tsx ==="
cat packages/components/src/ui/form.tsx | grep -A 1 "export const.*forwardRef"

echo -e "\n=== checkbox.tsx ==="
cat packages/components/src/ui/checkbox.tsx | grep -A 1 "export const.*forwardRef"

echo -e "\n=== radio-group.tsx ==="
cat packages/components/src/ui/radio-group.tsx | grep -A 1 "export const.*forwardRef"

# Also check FormItem usage in these components
echo -e "\n=== FormItem usage ==="
rg "FormItem" packages/components/src/ui/{text-field,form,checkbox,radio-group}.tsx

.changeset/heavy-dragons-drop.md (1)

6-6: Enhance the change description

The description could be more comprehensive and properly formatted:

-Added remix textarea story and fixes a react error
+Added Remix textarea story and fixed a React error. Also resolved issue #7 regarding unnecessary custom attributes on inputs.

🧰 Tools

🪛 LanguageTool

[grammar] ~6-~6: “React” is a proper noun and needs to be capitalized.
Context: ... Added remix textarea story and fixes a react error

(A_GOOGLE)

Configuration used: CodeRabbit UI
Review profile: CHILL